You can have different number of listening interfaces for HA pair (assuming
they are able to receive requests for all subnets). The “url” directive in the
HA hook configuration is for the Control-Agent (CA). The addr/port of the
Control-Agent is independent of the DHCP4 server and is
; Kraishak
>
> On Mon, Oct 16, 2023 at 9:09 PM Rick Frey <mailto:grib...@gmail.com>> wrote:
>> You can have different number of listening interfaces for HA pair (assuming
>> they are able to receive requests for all subnets). The “url” directive in
>> th
The listed Kea logs for DHCP_LEASE_ADVERT would indicate that Kea is sending an
OFFER to the DISCOVER request. It would seem unlikely that Kea logs the
ADVERT without attempting to send the offer packet on the network (such a bug
would likely affect more than your client). You also mention
Hello CS,
It is helpful to know which version of Kea you are using. Based upon your
earlier thread, assuming you are running Kea 2.2.0?
As noted in the Kea documentation, TLS support is provided by the underlying
crypto library used to build your package of Kea. See
Connection refused would indicate that kea-shell is unable to connect to
specified address and port. First step would be to verify the CA is listening
on the address and port you are specifying as args to kea-shell. Is the CA
listening on localhost (127.0.0.1 or ::1 if IPv6) and port 8000?
In
Per Kea docs, I believe kea will prefer the FQDN (81) option over the Hostname
(12) option if both are provided from client. Once name is derived from either
option, Kea then determines if name is fully qualified or a partial. In your
case, it seems that Kea determines the value in FQDN
The DNS response of RCODE 5 by your nameserver indicates the submitted DDNS
update was refused by the nameserver. May want to check your nameserver logs
for cause.Guessing it is not allowing your TSIG key used by Kea to make
updates to the 10.168.192.in-addr.arpa zone.
BIND will not create
If I’m reading logs correctly, your BIND nameserver is rejecting the update as
the Kea request is requiring NXRRSET (means the record cannot already exist in
the nameserver). I don’t see Kea config option to change that behavior. By
chance did you manually create the PTR record for
ate": true,
>
> Do I also need to add reverse zone 10.168.192.in-addr.arpa to the
> kea-dhcp4.conf?
>
> Any other thoughts or comments on this would be appreciated!
>
> -Ubence
>
>> On Jan 28, 2024, at 10:11 AM, Rick Frey wrote:
>>
>> The DNS response of
Depending upon the version and configuration, your prior version of ISC dhcpd
likely did not use DHCID records. The legacy ISC dhcpd could use TXT records
or none. See https://kb.isc.org/docs/aa-01091
Guessing your prior running dhcpd was only updating the PTR record for reverse
updates in
I believe that error indicates your Kea server requires a client certificate.
Per Kea documentation, the config parameter "cert-required” default is true.
Would indicate your server config didn’t set or is set to true and you did not
provide one in the sample command line. If you don’t
might not have done? "--ca
> Certificate_Autority.pem"
>
> CS, cs.temp.m...@gmail.com
>
>
> On Thu, 14 Mar 2024 at 11:22, Rick Frey <mailto:grib...@gmail.com>> wrote:
>> I believe that error indicates your Kea server requires a client
>> c
, cs.temp.m...@gmail.com
>
>
> On Thu, 14 Mar 2024 at 12:32, Rick Frey <mailto:grib...@gmail.com>> wrote:
>> When “cert-required” is set to true, you must provide a client certificate
>> and key to authenticate. A client cert is not required for using TLS
>>
13 matches
Mail list logo
